-
Notifications
You must be signed in to change notification settings - Fork 356
home: Show starred-message count in main menu, subject to user setting #1999
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
home: Show starred-message count in main menu, subject to user setting #1999
Conversation
|
cc @alya |
|
The screenshots look good to me! We should remember to note that the setting affects the mobile app in https://zulip.com/help/star-a-message#toggle-starred-messages-counter. |
Fixes-partly: zulip#1088
The buttons were 48px instead of 44px tall, and the label's line height was 26px instead of 23px.
5d32321 to
1e74454
Compare
rajveermalviya
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @chrisbobbe! LGTM and test great, moving over to Greg's review.
gnprice
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Here's comments on the first 7/8 commits, including the new data structure:
a3d7fd8 unreads [nfc]: Factor out countInAllDms, for public use and as a helper
45bfcb0 unreads: Exclude muted DM conversations in combined-feed and all-dm counts
248cab2 home: Show unread counts in main menu
e8f51b2 home: Tweak main-menu buttons to follow Figma
247a3d4 api: Add UserSettings.starredMessageCounts
a22b49f api: Add starredMessages to initial snapshot
34f9a0b message: Add MessageStore.starredMessages
and a brief look at the last commit with the UI changes:
1e74454 home: Show starred-message count in main menu, subject to user setting
| }; | ||
|
|
||
| if (isAdd && (event as UpdateMessageFlagsAddEvent).all) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: these stanzas don't become any more closely related with this change; in fact they become more separate, because this adds another stanza below which consumes isAdd separately
| /// All starred messages, as message IDs. | ||
| Set<int> get starredMessages; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I see.
I'm trying to think if there are other cases where this should get updated. I guess maybe not:
- We can learn of messages through handleMessageEvent. But maybe those can't ever be starred.
- We can learn of messages through reconcileMessages. But maybe if those are starred then they should already be in this set.
I think it'd be good to make that reasoning explicit, though, in those methods. Probably including asserts to verify those expectations.
| if (_messages.handleDeleteMessageEvent(event)) { | ||
| notifyListeners(); | ||
| } | ||
| unreads.handleDeleteMessageEvent(event); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes me a bit nervous to be calling notifyListeners at a point where the event has been only partially applied — the store is in a somewhat inconsistent state.
Instead let's delay the notifyListeners call to the end.
| await prepareMessages([message]); | ||
| check(store).starredMessages.single.equals(message.id); | ||
| await store.handleEvent(eg.deleteMessageEvent([message])); | ||
| checkNotifiedOnce(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is a bit confusing — it checks that the list view-model notified its listeners, but not whether the store did.
I think the key case here would actually be with prepareMessages not knowing about the message. That exercises the situation where the app hasn't gone and fetched a message list that had the starred message, and only knows about it through the list in the initial snapshot.
| void checkPerAccountStoreNotified({required int count}) { | ||
| check(perAccountStoreNotifiedCount).equals(count); | ||
| notifiedCount = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| void checkPerAccountStoreNotified({required int count}) { | |
| check(perAccountStoreNotifiedCount).equals(count); | |
| notifiedCount = 0; | |
| void checkPerAccountStoreNotified({required int count}) { | |
| check(perAccountStoreNotifiedCount).equals(count); | |
| perAccountStoreNotifiedCount = 0; |
right?
| await prepareMessages([message1, message2]); | ||
| check(store).starredMessages.isEmpty(); | ||
| await store.handleEvent( | ||
| mkAddEvent(MessageFlag.starred, [message1.id, message2.id])); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| await prepareMessages([message1, message2]); | |
| check(store).starredMessages.isEmpty(); | |
| await store.handleEvent( | |
| mkAddEvent(MessageFlag.starred, [message1.id, message2.id])); | |
| await prepareMessages([message2]); | |
| check(store).starredMessages.isEmpty(); | |
| await store.handleEvent( | |
| mkAddEvent(MessageFlag.starred, [message1.id, message2.id])); |
That way we check that it works both with messages that the message store knows about, and those that it doesn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Similarly for removing the flag, below.)
| class UnreadCountBadge extends StatelessWidget { | ||
| const UnreadCountBadge({ | ||
| /// See [CounterStyle] and [CounterKind] for the possible variants. | ||
| class Counter extends StatelessWidget { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe CounterBadge?
The name "counter" feels awfully generic — it doesn't sound like necessarily even a widget, more like some kind of data structure that keeps count of things.
Stacked atop #1998.
"Subject to user setting" refers to the "toggle starred messages counter" setting: https://zulip.com/help/star-a-message#toggle-starred-messages-counter
Fixes-partly: #1088